Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000027_owner-urn-ietf _Tue Nov 5 01:20:54 1996.msg

Internet Message Format | 1997-02-19 | 8KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA15027 for urn-ietf-out; Tue, 5 Nov 1996 01:20:54 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA15022 for <[e-mail]>; Tue, 5 Nov 1996 01:20:50 -0500
Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA29641  (mail destined for [e-mail]); Tue, 5 Nov 96 01:20:47 -0500
Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id AAA21984; Tue, 5 Nov 1996 00:16:00 -0600 (CST)
Date: Tue, 5 Nov 1996 00:16:00 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Message-Id: <[e-mail]>
To: Patrik Faltstrom <[e-mail]>
Cc: [e-mail]
Subject: Re: Names and Locations (was [URN] some comments)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

Patrik Faltstrom writes:
 > A URL refers to a location which though a caching mechanism, a proxy
 > cache, an interceptor with cache, multiple A-records in DNS or whatever
 > ends up refering to more than one occurance of the same resource.

But those multiple occurances of the resource are at multiple
locations, are they not?  (BTW, the point of this particular line of
argument is simply that the binding between URL and location is not as
clear as people are making it sound.  This, by itself, does not imply
that URLs are persistent, as URNs are intended to be.)

 > A URN is a _name_ of a resource which have absolutely _NOTHING_
 > to do with the resolution protocol, the different versions of
 > the resource that exist (text, postscript etc), the different
 > protocols used to locate and later fetch the resource or the
 > metadata for the resource.

I'm not sure who else would agree with you that a name is so abstract
that it has nothing to do with any of the information associated with
the resource.  If there is no association, how is that the name can
even be used as a name of the resource?    How would you ever get to
the resource?

Instead, perhaps you are trying to say that the name is not tightly
bound to information associated with the resource, that the
information can change and still the name is the name of the resource.
For example, the "resolution protocol" can change.  I have no problem
with that, and never have.  But this is still not abstractly different
from what happens to a URL.  What is happening when an HTTP server
gives you a redirect to an ftp URL?  Compare that to a DNS server for
a naming authority giving you a redirect to an http URL.

If you want to get from a URN to a resource, you must begin to look up
some information starting with the URN.  If you don't look up anything
associated with the URN, you can't continue with the resolution, so
there is something essential going on there, you must admit.  The
particular way you go about looking up the information is a process
that involves protocols itself.  (BTW, the point of this particular
line of argument is simply that if URLs have a protocol associated
with them, then so do URNs.  But in fact, different protocols can be
used to resolve either URNs or URLs.)

 > On Sun, 3 Nov 1996, Daniel LaLiberte wrote:
 > > But the very same URL was used to retrieve the resource either from a
 > > cache or from a remote server.  So what "location" is the URL
 > > identifying when the resource actually lives in multiple places - the
 > > very same URL may be used to fetch the resource from any of those
 > > places?  Notice you first say that a URL identifies (or names) the
 > > location of a resource, and then we find out that there are really
 > > multiple locations identified by the URL.  But that is supposed to be
 > > the job of URNs.  So why do we need URNs?

(BTW, my "So why do we need URNs?" is somewhat rhetorical.  I believe
we do need more persistent resolution services, in case that is not
clear.  The point of the above line of argument is, again, that the
binding between URLs and locations is not so clear.  There is more to
this argument that hasn't come out yet.)

...

 > Dan, you _have_ to start to differ between multiple locations
 > of a resource which is addressed by a URL - i.e. it's original
 > location,

Is your view that a URL *is* the "original" location of the resource
and also the URL "addresses" multiple locations of the resource?  This
is different from the definition that a URL identifies (or names) the
location of the resource.

 > and the functionality that is built into the system
 > when a _name_ is assigned to a resource. As long as you have not
 > seen this difference that many of us others have seen, it is
 > a little bit hard to have a meaningful discussion.

I see a difference, but it is not the difference you think it is.
There is a difference in the functionality that can be provided by a
new service, but it is not a difference because we call something a
"name" vs a "location".  The proof is that the things you call
"locations" (i.e. URLs) can use this new service too.

 > Sorry for being harsh and short, but I am now a little bit tired
 > of having to try to come up with exactly the same arguments we
 > have been having since the UR* discussions started. We have
 > to move forward!

I don't think these are exactly the same arguments - at least I havent
seen my arguments before.  But I didn't perceive harshness in your
words, or it didn't bother me anyway.  I am being patiently persistent
- I only hope that my readers are being persistent enough to
understand my arguments.

 > > A client can resolve
 > > "http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or
 > > something else.  This is the very same identifier, not two identifiers
 > > with the same character representation.  Calling it two identifiers
 > > and saying one is a name and the other is [the name of] a location is
 > > missing the whole point.
 >
 > No, _you_ are missing the point. By saying that
 > "urn:http://www.ncsa.uiuc.edu/" is a _name_, one know that this
 > namespace called HTTP can grandfather other namespaces, this
 > _name_ can stay as it is even if the resource moves, the metadata
 > for this resource can be fetched etc etc all according to the URN
 > spec that was written down years ago.

I'm not missing that point - I agree with it.  I helped create all
this, by the way, so I know what is going on here.

But I am not talking about "urn:http://www.ncsa.uiuc.edu/", I am
talking about "http://www.ncsa.uiuc.edu".  If the "urn:" prefix is
optional on URNs, then those two identifiers are equivalent.

Answer this: do you agree with the previous statement?

 > If you have a URL, like "http://www.ncsa.uiuc.edu/", what do you do
 > if you have to move this resource from the host www.ncsa.uiuc.edu?
 > Change things in the DNS? But of course that works. But, if you move
 > the information from staying only on an http server to also stay in
 > a Z39.50 database and want the clients to be able to use both, or
 > [...]


If "http://www.ncsa.uiuc.edu/" is in the "http" branch of the urn.net
tree, then you could do any of these things.  If some other name
resolution mechanism is created in the future, then
"http://www.ncsa.uiuc.edu/" could be registered there too.

 > There are thousands of things you _can_not_do_ with the name of a
 > location of something, that you only can do with a _name_ of a
 > resource which is resolved to one or many alternative locations.

If *you* define an identifier as a location and therefore limit what
you do with it based on that definition, then that's your choice.  But
anyone else is still free to use it as a name, if they can find a
resolution service that treats it as a name, in the sense of providing
persistent resolution, or any of the other thousands of things one
might associate with names.

--
Daniel LaLiberte ([e-mail])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/